Part Number Hot Search : 
710AS NC7NZ04 NCP15 NCP15 NCP15 VTT7123 Z102X NCP15
Product Description
Full Text Search
 

To Download PM8315 Datasheet File

  If you can't view the Datasheet, Please click here to try to view without PDF Reader .  
 
 


  Datasheet File OCR Text:
  downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use document id: pmc-2011388, issue 4 PM8315 temux tm temux high density t1/e1 framer with integrated vt/tu mapper and m13 mux errata for the production released device proprietary and confidential released issue 4: june 2002
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 2 document id: pmc-2011388, issue 4 legal information copyright ? 2002 pmc-sierra, inc. the information is proprietary and confidential to pmc-sierra, inc., and for its customers? internal use. in any event, you cannot reproduce an y part of this document, in any form, without the express written consent of pmc-sierra, inc. pmc-2011388 (r4) disclaimer none of the information contained in this document constitutes an express or implied warranty by pmc-sierra, inc. as to the sufficiency, fitness or suitability for a particular purpose of any such information or the fitness, or suitability for a particular purpose, merchantability, performance, compatibility with other parts or systems, of any of the products of pm c-sierra, inc., or any portion thereof, referred to in this document. pmc-sierra, inc. expressly disclaims all representations and warranties of any kind regarding the contents or use of the information, including, but not limited to, express and implied warranties of accuracy, completeness, merchantability, fitness for a particular use, or non-infringement. in no event will pmc-sierra, inc. be liable for any direct, indirect, special, incidental or consequential damages, including, but not limited to, lost profits, lost business or lost data resulting from any use of or reliance upon the information, whether or not pmc-sierra, inc. has been advised of the possibility of such damage. trademarks sbi, temux, and pmc-sierra are trademarks of pmc-sierra, inc. other product and company names mentioned herein may be the trademarks of their respective owners. patents the technology discussed may be protected by one or more patents. relevant patent applications and other patents may also exist .
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 3 document id: pmc-2011388, issue 4 contacting pmc-sierra pmc-sierra 8555 baxter place burnaby, bc canada v5a 4v7 tel: +1.604.415.6000 fax: +1.604.415.6204 document information: document@pmc-sierra.com corporate information: info@pmc-sierra.com technical support: apps@pmc-sierra.com web site: http://www.pmc-sierra.com revision history issue no. issue date details of change 4 june 2002 notification of additional information and errors to temux data sheet issue r7, temux register description r5 and temux programmer?s reference guide r3. added items 2.3 to 2.6, 3.7 to 3.18. 3 october, 2001 notification of additional information and errors to temux data sheet issue r7 and temux register description r5. 2 august, 2001 notification of additional information and errors to temux data sheet issue r7 and temux register description r5. 1 april 23, 2001 document created.
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 4 document id: pmc-2011388, issue 4 table of contents legal inform ation .............................................................................................................. .. 2 contacting pmc-sierra ....................................................................................................... 3 table of contents .............................................................................................................. .. 4 1 introduction.................................................................................................................. 6 1.1 device identif ication............................................................................................ 6 1.2 references ......................................................................................................... 7 2 device functional deficiency list ............................................................................... 8 2.1 use of hdlc controller in e1 mode................................................................... 8 2.2 vt-ais tributary corruption................................................................................ 8 2.3 ds3 prgd block limits useable repeating patterns in unchannelized m23 mode ............................................................................................................................ 9 2.3.1 description ............................................................................................. 9 2.3.2 workaround.......................................................................................... 10 2.3.3 performance with workaround ............................................................ 10 2.3.4 performance without workaround ....................................................... 10 2.4 demapping ds3 when clk52m = 51.84 mhz is not recommended ............... 10 2.4.1 description ........................................................................................... 10 2.4.2 workaround.......................................................................................... 11 2.4.3 performance with workaround ............................................................ 11 2.4.4 performance without workaround ....................................................... 11 2.5 incorrect link rate octet generated when demapping ds3 from sonet ...... 11 2.5.1 description ........................................................................................... 11 2.5.2 workaround.......................................................................................... 12 2.5.3 performance with workaround ............................................................ 12 2.5.4 performance without workaround ....................................................... 12 2.6 automatic sbi tributary reset not available when mixing sync and async tribs per spe .......................................................................................................................... 13 2.6.1 description ........................................................................................... 13 2.6.2 workaround.......................................................................................... 13 2.6.3 performance with workaround ............................................................ 13 2.6.4 performance without workaround ....................................................... 13 3 documentation deficiency list .................................................................................. 14 3.1 connecting to the telecom add bus via an external mux ............................... 14 3.2 telecom bus parity generation ........................................................................ 14
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 5 document id: pmc-2011388, issue 4 3.2.1 telecom add bus pari ty generation................................................... 14 3.2.2 telecom drop bus parity detection .................................................. 14 3.3 byte deletion/insertion in vt/tu mapping mode ............................................. 15 3.4 duplication of ground pin descriptions............................................................ 15 3.5 ais insertion in ds3 diagnostic loopback....................................................... 16 3.6 path signal label mismatch state.................................................................... 16 3.7 transmultiplexing mode clarification................................................................ 16 3.8 e1 multiframe pulse configurations .................................................................. 17 3.9 cent bit description of tjat and rjat configuration registers are incorrect 18 3.10 m13 tjat and rjat settings incorrect in programmer?s guide ...................... 18 3.11 iilpu max spec limit has been revised ............................................................ 18 3.12 revision id bits section incorrect .................................................................... 19 3.13 egress mode settings incorrect for clock slave: clear channel...................... 19 3.14 clk52m clarif ication ........................................................................................ 19 3.15 recommended rtdm leak rate incorrect...................................................... 20 3.16 behavior of fifo status handling needs clarification ....................................... 20 3.17 insbi automatic depth check logi c behavior clar ificatio n................................. 20 3.18 rjat sync bit description in exsbi clk_mode field clarified ..................... 21
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 6 document id: pmc-2011388, issue 4 1 introduction in this document:  section 2 lists the known functional errata for the production released version of the PM8315 temux.  section 3 lists documentation errors found in issue 7 of the PM8315 temux datasheet (pmc-1981125), issue 5 of the PM8315 temux register description (pmc-1990495) and issue 4 of the PM8315 temux programmer?s reference guide (pmc-1991268). 1.1 device identification the information contained in section 2 relates to the production released version of the PM8315 temux device only. the device revision code is marked at the end of the wafer batch code on the face of the device. register 0002h: revision/global pmon update identifies the production release revision of the PM8315 temux using the type identification bits 0101. note: this errata only applies to issues specific to the production released PM8315-pi temux device. it does not apply to any of the prototype temux devices. the prototype temux devices are denoted with a ?p following the part number that is labeled on the device (ie. PM8315-pi-p signifies a prototype while PM8315-pi signifies a production part). the errata for the prototype temux devices is contained in the PM8315 temux datasheet errata (pmc-1990677, r9) available from your local sales representative. figure 1 PM8315 branding diagram PM8315-pi c g myyww philippines pmc logo part number temux logo ball a1 index marks assembly date code wafer batch code tm t emux country of assembler
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 7 document id: pmc-2011388, issue 4 1.2 references  issue 7 of the PM8315 temux datasheet (pmc-1981125).  issue 4 of the PM8315 temux programmer?s reference guide (pmc-1991268).  issue 5 of the PM8315 temux register description (pmc-1990495)
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 8 document id: pmc-2011388, issue 4 2 device functional deficiency list this section lists the known functional deficiencies for the production released version of the PM8315 temux as of the publication date of this document. please report any functional deficiencies not covered in this errata to pmc-sierra. 2.1 use of hdlc controller in e1 mode when using the internal hdlc controllers in e1 mode there are some restrictions to be aware of:  if data is inserted into a timeslot from the internal hdlc controller and the previous timeslot has an idle code byte inserted from the tpsc, the last two bits of the idle code can be corrupted. this means that if timeslot 4 has data inserted from the hdlc controller, and an idle code has been inserted in timeslot 3 fr om the tpsc, the least significant two bits of timeslot 3 can be corrupted. it is recommended that hdlc traffic be inserted from the backplane rather than the internal controller if idle codes are being transmitted in the preceding timeslot.  if data is inserted into timeslot 1 from the in ternal hdlc controller, the least significant bit in timeslot 0 for nfas frames only (i.e., sa8) can be corrupted if configured to come from the backplane. the national use bits codeword, however, operates correctly on sa8 if enabled. it is recommended that timeslot 1 not be used for hdlc traffic inserted from the internal controller.  in normal operation, if a timeslot is configured for both hdlc transmission and idle code insertion, hdlc is supposed to be transmitted and the idle code ignored. it is possible in temux for the last two bits of the hdlc data to be corrupted. to get around this, simply disable idle code insertion for that timeslot when hdlc data is being transmitted.  inserting hdlc data into the national bits sa8, sa7, sa6, or sa5 can cause the neighboring more significant bit to be corrupted. for example, if hdlc is inserted into sa7, then sa6 can be corrupted, but only if sa6 is inserted from the backplane. the national bits are always inserted error-free when they are generated via the national bits codeword register of the e1- tran block.  inserting hdlc data into the si bit in ts0 (i.e., the international bit) can cause the least significant two bits of an idle code in ts31 to be corrupted. 2.2 vt-ais tributary corruption an issue in the temux demapper results in the vt-ais causing corruption to the previous tributary of spe#3 only. to circumvent this issue, apply the software workaround outlined in section 16 of the programmer?s reference guide (pmc-1991268).
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 9 document id: pmc-2011388, issue 4 2.3 ds3 prgd block limits u seable repeating patterns in unchannelized m23 mode 2.3.1 description as described in the temux data sheet, section 12.1: ds3 framing format, the temux device provides support for both the c-bit parity and m23 ds3 framing formats. the ds3 frame format is shown in figure 13 of the data sheet (copied below): x 1 f 1 c 1 f 2 c 2 f 3 f 4 c 3 x 2 f 1 c 1 f 2 c 2 f 3 f 4 c 3 p 1 f 1 c 1 f 2 c 2 f 3 f 4 c 3 p 2 f 1 c 1 f 2 c 2 f 3 f 4 c 3 m 1 f 1 c 1 f 2 c 2 f 3 f 4 c 3 m 2 f 1 c 1 f 2 c 2 f 3 f 4 c 3 m 3 f 1 c 1 f 2 c 2 f 3 f 4 c 3 84 bits 84 bits 84 bits 84 bits 84 bits 84 bits 84 bits 84 bits m-subframe 1 m-subframe 7 m-subframe 6 m-subframe 5 m-subframe 4 m-subframe 3 m-subframe 2 the c-bit parity id bit is the first c-bit (c 1 ) of the m-subframe 1. in the receive direction, the cbitv register bit in the ds3 frmr status register is used to report the state of this c-bit parity id. if the id bit is 1, the ds3 frame received is assumed to be c-bit parity. if the c-bit parity id is 0 or toggling, the ds3 signal stream received is assumed to be m23. unchannelized repeating patterns are regenerated each time the prgd pattern insertion register #4 is written to (register 103bh). in m23 mode, the ds3 prgd always sets all c-bits to the same value, a value based on the last transmitted bit. for an all-1?s pattern, all c-bits will be 1. similarly for an all-0?s pattern, all c-bits will be 0. for an alternating 10101010 pattern for instance, there is a 50/50 chance of all c-bits being 1. an issue arises when attempting to generate an unchannelized all-1?s m23 pattern. recall that an m23 signal stream would require the c-bit parity id to be 0 or toggling. however, the ds3 prgd will set all c-bits (and hence the c-bit parity id) to 1 when generating an all-1?s pattern. the receiver will therefore interpret the ds3 frame to be c-bit parity rather than the correct m23 format. as a result, a frame mismatch would be declared if an all-1?s is generated in m23 mode. similarly, an alternating 10101010 m23 pattern has a 50/50 chance of being misinterpreted as a c-bit parity ds3 stream while in unchannelized ds3. for patterns containing one or more 0?s, the occurrence of this problem is related to the 1?s density of the pattern. an example is a 31- ones, 1-zero pattern in m23 mode. on average, this pattern will work without frame mismatch one every 32 tries, as there is a 1/32 chance of c-bit parity id being 0. in c-bit parity mode, there are no problems passing all-1?s because the id bit is always overwritten with a 1.
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 10 document id: pmc-2011388, issue 4 2.3.2 workaround there is no way to generate an all-1s pattern while in unchannelized m23 mode without seeing frame mismatch errors. because the ds3 prgd block limitation applies to unchannelized ds3 only, utilizing c-bit parity mode (instead of m23) allows the generation of an all-1?s pattern. in the event that unchannelized m23 mode must be used, several other patterns can be used without declaring ds3 frame mismatch. for patterns containing one or more 0?s, the occurrence of this mistaken m23 signal for c-bit parity is related to the 1?s density of the pattern. the following algorithm can be used to to generate patterns other than all-1?s in m23 mode:  write to prgd pattern insertion register #4 (register 103bh) to generate unchannelized repeating patterns.  at the receiver, check the framer for a ds3 frame mismatch. if using a loopback or another temux, the ds3 framing circuitry of the temux reports the frame mismatch using ds3 frmr status bit cbitv.  if frame mismatch has occurred, repeat. else, transmitted pattern is correct. an all-0?s pattern can always be transmitted correctly while the temux is in unchannelized m23 mode. 2.3.3 performance with workaround there is no workaround to implement the generation of an all-1s pattern while in unchannelized m23 mode. using c-bit parity ds3 framing format is recommended to generate all-1?s. the temux device will operate normally in ds3 testing scenarios with the suggested workaround in place for m23 mode. 2.3.4 performance without workaround ds3 frame mismatch will be declared when attempting to generate all-1?s pattern in unchannelized m23 mode. 2.4 demapping ds3 when clk52m = 51.84 mhz is not recommended 2.4.1 description in the temux data sheet, there is a choice between two clock frequencies for clk52m input (pin p3): " the 52mhz clock reference is used to generate a gapped ds3 clock when demapping a ds3 from the sonet stream and also to generate a gapped ds3 clock when receiving a ds3 from the sbi bus interface. this clock has two nominal values.
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 11 document id: pmc-2011388, issue 4 the first is a nominal 51.84mhz 50% duty cycle clock. the second is a nominal 44.928mhz 50% duty cycle clock. when this clock is not used this input must be connected to ground." repetitive data corruption with demapped ds3 may occur in systems using the 51.84 mhz clock. it has been confirmed that this is not an i ssue if the alternate clock frequency, 44.928 mhz, is used. when 51.84mhz is synchronized to lrefclk, errors still occur as long as the incoming ds3 ppm offset is greater than the relative offset of the 51.84mhz. the data corruption is theoretically possible with or without incoming sts level pointer movements. at this time however, no errors have ever been observed in the absence of sts level pointer movements. also, standard test equipment used as the mapped ds3 source has yet to produce the error condition. only a temux device mapping the ds3 causes the errors. 2.4.2 workaround when configured to demap ds3 payloads from sonet sts1/sdh au3, the clk52m input being 44.928mhz would avoid this possible data corruption to the ds3 stream. thus, the fastclkfreq bit of register 1209h must be cleared to logic 0. using the 44.928mhz clock has always been a fully supported mode of the temux. 2.4.3 performance with workaround if the 44.928mhz clock frequency is used for clk52m while demapping ds3s from sonet sts1/sdh au3, the risk of data corruption in this mode no longer exists. it is highly recommended to use this clock frequency when demapping ds3s in new temux designs going forward. 2.4.4 performance without workaround when demapping ds3s from sonet/sdh payloa ds, if the clk52m input is set to 51.84mhz, there is a risk of data corruption. it is highly recommended to use 44.928mhz crystals for new designs. 2.5 incorrect link rate octet ge nerated when demapping ds3 from sonet 2.5.1 description when the temux device is in ds3 framer-only mode, the linkrate clock rate field over the sbi bus tolerates approximately 4 ui of jitter in a 500us (2khz) period. when demapping a ds3 from sonet, gapping the clk52m reference clock generates the serial ds3 clock. the gapping procedure utilizes fifo depth to control the gapping algorithm.
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 12 document id: pmc-2011388, issue 4 the gapping algorithm used by the ds3 demapper exc eeds the jitter tolerance of the sbi linkrate. data taken by the link layer sbi devices via their exsbi fifo is derived from these faulty linkrate values. these values no longer match the actual data rate. with the clock rate octet enabled in layer 2 sbi devices, the ds3 clock could only be varied by a few ppm before the exsbi fifo underflows or overflows. as a result, data corruption can occur. therefore, when demapping ds3s from sonet in the temux, the layer 2 sbi devices cannot rely upon link rate octet to regenerate clocking. rather, the ds3 serial clocks need to be routed around the sbi bus. the only affected applications are those in which link rate may be relied upon: 1. aal1 circuit emulation, involving temux and aal1gator devices. in fact, for this application, it is always recommended to route the ds3 timing around the sbi bus even in ds3 liu applications. for ds3 mapping applications, an additional external ds3 jat is required to smooth the ds3 clock before it is fed into the aal1gator32 device. 2. back-to-back temux devices over sbi. data applications, such as those involving temux and freedm packet processing or ima atm are completely unaffected by this problem. these particular link layer devices do not utilize link rate values. 2.5.2 workaround in data applications involving freedm packet processing and ima atm, the fifo method is used to pass data across the sbi bus when demapping ds3 from sonet. hence, an incorrect link rate octet does not affect these applications. however, for aal1 circuit emulation (ces) ap plications that demap ds3 from sonet, the serial ds3 clocks (generated by gapping clk52m) need to be routed around the sbi bus. this is normally done for serial ds3 but in addition, a ds3 jat is required for demapping applications. refer to pmc-1990887 ?aal1gator-32 ces reference design?, issue 5 for details. 2.5.3 performance with workaround if the serial ds3 clocks are routed around the sbi bus in ds3 demapping ces applications, there will be no excess jitter introduced. 2.5.4 performance without workaround data corruption may occur when demapping ds 3s from sonet in aal1 circuit emulation.
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 13 document id: pmc-2011388, issue 4 2.6 automatic sbi tributary reset not available when mixing sync and async tributaries per spe 2.6.1 description in the insbi control register 1720h, the dc_rst en bit controls the insbi automatic depth check logic, whereby the link will automatically reset upon detection of a depth check error, i.e. insbi underrun or overflow. when the dc_rsten bit is set to 1, the automatic reset is enabled. if dc_rsten is set to 0, the link must be manually reset upon depth interrupt. however, there is a limitation to this automatic depth check logic. in register 1726h: insbi tributary control indirect access data, the synch_trib bit controls whether tributaries operate in synchronous mode on the sbi drop bus. however, when there is a mix of synchronous and non-synchronous tributaries, i.e. synch_trib = 1 for some and synch_trib=0 for others, the insbi automatic depth check logic does not operate properly. hence, underflows or overflows in the sbi fifos are not serviced with a link reset. data corruption may occur as result. as stated in errata item 3.17, dc_rsten should not be set to 1 when insbi synch_trib bit (register 1726h: insbi tributary control indire ct access data) settings are mixed between 0 and 1, indicating only some tributaries are synchronous to the sbi bus?. 2.6.2 workaround when underruns or overruns are detected via the interrupt indications of registers 1721h or 1722h respectively, the tributary must be manually reset to clear the error condition. to reset a given tributary, an indirect write access must be performed to register 1726: tributary control ram indirect data register for the errored tributary, with the last value written to the register. this will write a logic 1 to the enbl bit that will trigger a reset of that tributary. 2.6.3 performance with workaround device operates normally after a manual reset of the errored tributary 2.6.4 performance without workaround without manually resetting the tributary, it may never exit the errored state and data corruption will result.
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 14 document id: pmc-2011388, issue 4 3 documentation deficiency list this section of the document is a notification of additional information to issue 7 of the PM8315 temux datasheet (pmc-1981125) and issue 5 of the PM8315 temux register description (pmc-1990495). this section also lists the known documentation deficiencies for issue 7 of the PM8315 temux datasheet (pmc-1981125) and issue 5 of the PM8315 temux register description (pmc- 1990495) as of the publication date of this document. please report any documentation deficiencies not covered in this errata to pmc-sierra. 3.1 connecting to the telecom add bus via an external mux the pin description for lac1j1v1 may need clarification. when connecting the temux to the telecombus via an external mux (instead of simply tri-stating the bus), the lac1j1v1 signal should not be muxed. this means that when there are three temuxs connected to a spectra?s telecombus through the mux, the lac1j1v1 signal from only one of the three temuxs should be connected to the spectra. the other two lac1j1v1 signals should remain unconnected. all temuxs must have the lock0 bit in registers 1202h and 15e5h set the same. 3.2 telecom bus parity generation 3.2.1 telecom add bus parity generation the temux device cannot generate parity on the telecom add bus when lac1j1v1 is set to participate in the egress parity generation. parity generation only helps check integrity of the bus connections and have no effect on the data path or with control of the device. if egress parity needs to be generated, lac1j1v1 should not be used. 3.2.2 telecom drop bus parity detection the temux device can correctly detect parity on the telecom drop bus when ldc1j1v1 is set to participate in the ingress parity detection. the register description documentation is erroneously missing this optionally selectable feature. accordingly, register 1201h of the register de scription document should be amended as shown in the following table:
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 15 document id: pmc-2011388, issue 4 register 1201h: sonet/sdh master ingress configuration bit type function default bit 7 r/w ldpe 0 bit 6 r/w itmfen 0 bit 5 r/w ivtppbyp 0 bit 4 r/w itsen 0 bit 3 r/w incldpl 0 bit 2 r/w incldc1j1v1 0 bit 1 r/w ldop 0 bit 0 r/w iconcat 0 incldc1j1v1: the incldc1j1v1 bit controls whether the ldc1j1v1 input signal participates in the incoming parity calculations. when incldc1j1v1 is set high, the parity signal set includes the ldc1j1v1 input. when incldc1j1v1 is set low, parity is calculated without regard to the state of ldc1j1v1. selection of odd or even parity is controlled by the ldop bit. 3.3 byte deletion/insertion in vt/tu mapping mode while rare, it is possible for jitter on xclk or the selected t1/ e1 transmit clock to cause an overflow or underflow in the transmit mapper (t tmp) fifo. the t1/e1 transmit timing can be sourced from the two clock master sources, the ctclk input or the recovered t1/e1 clock, or from the four clock slave sources, the ceclk in put, the h-mvip clock input, an eclk[x] input or the sbi tributary rate received on the sbi add bus. by design, underflow or overflow will result in the loss of a byte of data. the initialization procedure shown in section 16 of the programmer?s reference guide will push the fifo closer to the center such that it can withstand more jitter from these clocks to reduce any impact on the datapath. if the fifo is close to an underflow or overflow condition and jitter does push it over or under, the fifo will insert or delete a byte of data, pushing itself away from these states and giving itself at least another 8 ui of margin against future jitter events on xclk or the selected t1/e1 transmit clock. you should use the initialization sequence shown in section 16 of the programmer?s reference guide (pmc-1991268). 3.4 duplication of ground pin descriptions the description of ground pins n3, y12, l20 and b 12 has been duplicated in two rows of the pin description section, pins vssq[1:4] and vss3.3[19:22]. these pins should only be described in the vss3.3 row. the vssq row should be eliminated. in any event these pins should be connected to gnd as described.
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 16 document id: pmc-2011388, issue 4 3.5 ais insertion in ds3 diagnostic loopback in the datasheet, figure 2: ds3 diagnostic loop back diagram states that ais can optionally be inserted into the transmit datapath when a ds3 is in diagnostic loopback. this is incorrect. ais cannot be inserted in the transmit path when in ds3 diagnostic loopback mode. 3.6 path signal label mismatch state in the datasheet, table 1: path signal label mismatch state is incorrect. it incorrectly references pdi code. the table should read as follows: table 2 - path signal label mismatch state expected psl accepted psl pslm state 000 000 match 000 001 mismatch 000 xxx  000 mismatch 001 000 mismatch 001 001 match 001 xxx  001 match xxx  000, 001 000 mismatch xxx  000, 001 001 match xxx  000, 001 xxx match xxx  000, 001 yyy mismatch 3.7 transmultiplexing mode clarification transmultiplexing mode (?transmux?) is not adequately described in the current temux datasheet. this mode enables the exchange of 1.544mbps tributaries between sonet/sdh telecombus and ds3 line interface. the following excerpt should be added to section 9: functional description:
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 17 document id: pmc-2011388, issue 4 transmultiplexing (?transmux?) is the operating mode that enables 1.544 mb/s clear- channel tributaries to be exchanged between the sonet/sdh telecom bus and the ds3 line interface. it is enabled by setting the temux configuration register?s opmode[1:0] bits to 10 and its lineopt [1:0] bits to 00. the system interface is unused in this mode. the temux will receive a channelized ds3 stream from the serial ds3 interface. it will frame up to the ds3 and de-multiplex the individual 1.544 mb/s tributaries. the tributaries are jitter attenuated, bit asynchronously mapped into vt1.5/tu11s and presented on the telecom add bus. in the reverse direction, vt1.5/tu11s are bit asynchronously de-mapped from the telecom drop bus. the 1.544 mb/s tributaries are jitter attenuated and multiplexed into a ds3, which is presented on the serial ds3 interface. performance monitoring of t1 framing status and errors can be performed on the tributaries. on a per-tributary basis, the txpmon context bit programmed through register 000h+80h*n: t1/e1 master configuration register selects either the sonet/sdh mapper transmit or ds3 transmit t1 tributary for performance monitoring. 3.8 e1 multiframe pulse configurations the imfpcfg[1:0] bits in regist er 005h+80h*n (t1/e1 ingress serial interface mode select) select whether ifp[x] (ingress frame pulse) in dicates e1 crc, signaling or both crc and signaling multiframe boundaries. these bits must be configured in e1 or sbi modes. these ifp[x] modes are listed in table 3 in the temux register description as follows: table 3: ingress frame alignment configuration imfpcfg[1] imfpcfg[0] operation 0 0 both e1 crc and signaling multiframe 0 1 e1 crc multiframe 1 0 e1 signaling multiframe 1 1 both e1 crc and signaling multiframe however, these bits should be set to signaling mf pulses in e1 mode of the temux as follows: 1. basic framing without cas: must use signaling multiframe pulse, imfpcfg[1:0]=10 2. crc-4 multiframe without cas: a. signaling multiframe pulse imfpcfg[1:0]=10, or b. crc multiframe pulse imfpcfg[1:0]=01
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 18 document id: pmc-2011388, issue 4 3. cas modes: basic framing with cas or crc-4 multiframe with cas: a. signaling multiframe pulse imfpcfg[1:0]=10 3.9 cent bit description of tjat and rjat configuration registers are incorrect the following text should be ignored from the cent bit description of the t1/e1 tjat and rjat configuration registers, register 0017h + 80h*n and register 0013h + 80h*n respectively: ?it is recommended to set this bit to 1?. for the recommended setting of the tjat and rjat configuration register bits, refer to section 16 of the temux programmer?s guide for vt/tu mapping modes and to errata item 3.10 below for the ds3 m13 operational modes. 3.10 m13 tjat and rjat settings incorrect in pr ogrammer?s guide the tjat and rjat configuration register recommendations are incorrect in the temux programmer?s guide for channelized ds3 applications. sections 6.2.1 (t1) and 7.1.1 (e1) state the tjat and rjat manual centering procedures setting register 0017h + 80h*n tjat configuration and register 0013h + 80h*n rjat configuration to values of 0x20 . neither centering procedure should be followed for channelized ds3 t1 or e1 applications. rather, these two registers should be programmed with values of 0x31 upon initialization for all modes. the only exception is where pm73122 aal1gator-32 is connected to the temux?s system side sbi bus and operating in srts mode. in this particular application, the rjat configuration register 0013h + 80h*n must be set to 0x23 . the temux programmers guide?s tu mapping mode recommendations for tjat and rjat configuration registers in section 16 are correct and should be followed. this includes the manual centering routine for the tjat and rjat in section 16.1.1. 3.11 iilpu max spec li mit has been revised in table 44, the d.c. characteristics table, the input low current parameter, iilpu maximum has been changed from +100  a to +150  a.
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 19 document id: pmc-2011388, issue 4 3.12 revision id bits section incorrect the temux revision id is located in id[3:0] bits of register 0x02, not type[3:0] as incorrectly stated in a previous errata document (pmc-1990677, temux datasheet errata, issue 9, section 7). 3.13 egress mode settings incorrect for clock slave: clear channel in register 006h+80h*n: t1/e1 egress serial interface mode select, the egress clock mode, emode, bit determines which serial interface mode is being used for this tributary. in table 44 of temux register description i ssue 5, the clock slave: clear channel operation should be configured by emode[2:0] = 010, not 01x. the correct table should read as follows: emode[2] emode[1] emode[0] operation 1 0 x clock master: nxchannel 1 1 x clock master: clear channel 0 0 1 clock slave: efp enabled 0 0 0 clock slave: external signaling 0 1 0 clock slave: clear channel 3.14 clk52m clarification in section 9.32.3 ds3 desynchronizer of the temux data sheet, the following statement is misleading: ?the desynchronizer monitors the elastic store level to control the de-stuffing algorithm to avoid overflow and underflow conditions. the desynchronizer assumes either a 51.84 mhz clock (provided internally) or a 44.928 mhz clock (provided via input clk52m).? the 51.84mhz clock option is not provided intern ally within the temux device. hence, ds3 signals cannot be transported without connecting clk52m.refer also to errata section 2.4 for clk52m discussion when demapping ds3s.
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 20 document id: pmc-2011388, issue 4 3.15 recommended rtdm leak rate incorrect it was incorrectly recommended in the temux programmer?s guide, section 16.4 b) ?register 12e0h: rtdm pointer justification rate c ontrol? that e1rate[1:0] be set to 10. the recommended settings should read e1rate[1:0]=00, the default and slowest leak rate settings to ensure no degradation of jitter performance. 3.16 behavior of fifo status handling needs clarification in the extract and insert sbi (exsbi, insbi) fifos, the temux has a priority mechanism for reporting underruns and overruns on certain tributaries. in general, lower-numbered tributaries can seemingly block the reporting of fifo events on higher-numbered tributaries. consider an example where all tributaries underrun continuously. after reading status register errors for the first few tributaries, it may be the case that new underrun events are registered. in this case, errors will appear again for lower number tributaries before errors for higher number tributaries can be read. in general, errors for a particular tributary cannot be read from the status register if an error on any lower numbered tributary has not been read. this behaviour will only become evident in the rare event that several tributaries are simultaneously exhibiting fifo errors. note that this priority mechanism does not inhibit normal behavior of the temux device. 3.17 insbi automatic depth check logic behavior clarification the following clarification needs to be made regarding the behavior of the insbi automatic depth check logic: append the following statement to the dc_rsten bit descript ion found in register 1720h: insbi control and synch_trib bit descripti on in register 1726h: insbi tributary control indirect access data: ?the insbi automatic depth check logic does not support a mix of synchronous and non- synchronous tributaries, i.e. dc_rsten should not be set to 1 when insbi synch_trib bit (register 1726h: insbi trib utary control indirect access data) settings are mixed between 0 and 1, indicating only some tributaries are synchronous to the sbi bus?.
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 21 document id: pmc-2011388, issue 4 3.18 rjat sync bit description in exsbi clk_mode field clarified in register 1716h: exsbi tributary control indirect access data, the clk_mode[1:0] bit bndescription includes the following statement: "when using the phase field of the link rate octet, the sync bit in the rjat configuration register needs to be set." for clarification, the temux rjat is not usually connected to the temux exsbi. hence, this comment about the ?phase field? is more relevant to the device that uses this information, pm73122 aal1gator-32?s exsbi, rather than temux.
downloaded by vinve fu of olivetti on thursday, 19 september, 2002 10:10:10 pm temux production release errata released proprietary and confidential to pmc-sierra, inc., and for its customers? internal use 22 document id: pmc-2011388, issue 4 notes


▲Up To Search▲   

 
Price & Availability of PM8315

All Rights Reserved © IC-ON-LINE 2003 - 2022  

[Add Bookmark] [Contact Us] [Link exchange] [Privacy policy]
Mirror Sites :  [www.datasheet.hk]   [www.maxim4u.com]  [www.ic-on-line.cn] [www.ic-on-line.com] [www.ic-on-line.net] [www.alldatasheet.com.cn] [www.gdcy.com]  [www.gdcy.net]


 . . . . .
  We use cookies to deliver the best possible web experience and assist with our advertising efforts. By continuing to use this site, you consent to the use of cookies. For more information on cookies, please take a look at our Privacy Policy. X